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(54) Methods, systems, and computer program products for storing, loading, analyzing, and 
sharing references to recently used objects 



(57) Metfxx!s. systems, and computer program 
products centrally manage references to objects 
recently employed by a user operating in a software 
development environment After transmission of collec- 
tion messages to plural applications (324, 328), a 
receiver (310) centrally managing object references 
receives an information block of object references. A 



writer (304) of the centrally managing object references 
system writes the information bUocks into memory (320). 
A reader (304) further reads previously written informa- 
tion blocks to inform plural applications (324. 328) of 
what objects were previously referenced. 
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Description 

CROSS-REFERENCE TO RELATED APPUCAT10N 

Related applications include "METHODS, SYS- s 
TEMS, AND COMPUTER PROGRAM PRODUCTS 
FOR CONTROLLING PICKLISTS." to Daniel J. 
O'Leary, U.S. Patent Serial Number 

; and THIRD-PARTY TOOL 

INTEGRATION," to Daniel J. O'Leary and David A. Nel- io 
son-Gal. U.S. Patent Serial Number 

. These applications are filed on 

even date herewith, and the contents thereof are 
expressly incorporated herein by reference (see Appen- 
dix D and Appendix E). 75 

RELD OF THE INVENTION 

TTie present Invention relates to software develop- 
ment tools and integrated computer software develop- 20 
ment environments, and more particularly to methods, 
systems, and computer program products for manag- 
ing, storing, tracking, loading, and sharing references to 
objects such as source f 3 es, object files, source browser 
directories, and build targets, which are used in soft- 2s 
ware development sessions. 

BACKGROUND OF THE INVENTION 

Selected computer software applications remem- 30 
ber files used in recent program runs. Word processors 
such as WordPerfect for Windows particularly remem- 
ber a limited number of recentiy used files, whether 
merely opened or actually saved. The ofder and the 
content of remembered lists of objects, including 35 
recentiy used files, are immutably fixed and controlled In 
these application programs. In one application, the 
order of the lists is updated only when a most recently 
used file in the list ceases to t>e the first entry on the list 
In one other application which supports limited lists hav- 40 
ing a fixed nwimum size, the addition of a new file to 
the list beyond the list maximum causes the oldest file in 
the list to be deleted. Thus, room is made for a new f Qe 
entry, and the order of items In the list Is updated to 
ensure that the most recently used file is first on the list 45 
Such rigid approaches are of limited utility. 

In known integrated software development environ- 
ments, such as Symarrtec's Think C environment and 
Apple's Programmer's Workshop, file names relating to 
a selected project are stored in one or more lists to ena- so 
ble a programmer to track tiie files required to "buiM" a 
desired project These lists are only updated when the 
files belonging to a project are modified. Even this 
approach is severely limited. 

It is difficult tor programmers to track recentiy used ss 
files, programs, and associated software tools, t>ecause 
of lack of a central tracking mechanism for such objects. 
This technical prot)lem of lacking a central mechanism 



Is In need of a solution. Lacking such centralized track- 
ing, programmers are forced latx>riously to shutUe 
between applications to collect information. It is. for 
example, particularly desirable to maintain references to 
particular files used in a well-known UNIX *make' utii'rty, 
to desaibe which programs are built with v^ich compo- 
nents, and to desait>e when changes to a first file 
require tfiat a second file t>e re-compiled or when a pro- 
gram needs to be re-linked. A tool for aiding program- 
mers In centrally tracking which files have been used 
recently and by v^ich software tools tiiey have been 
used, wouM certainly be desired in the software arxJ 
computer arts. 

SUMMARY OF THE INVENTION 

According to the present Invention, a custom soft- 
ware devek}pment environment manages, centrally 
tracks, and stores information identifying recentiy used 
objects (e.g., source files, object files, source browser 
directories, and build targets) that have been visited or 
used in a selected software development work session. 

According to one embodiment of the present Inven- 
tion, a computer program product is embodied in code 
which is transformable by compilation into a form which 
can control a microprocessor to accomplish messaging 
t>etween specialized tools of a selected integrated soft- 
ware development environment. In particular, the micro- 
processor controlled by the conrputer program product 
according to the present invention informs the respec- 
tive specialized tools used in the integrated software 
development environment of recentiy used objects, 
which are to be added to or rerrKived from particular 
tool-specific information lists. According to the present 
invention, particular tool specif k; lists contain references 
to recentiy used objects for a given tool. The tool spe- 
cific lists are combined into a central list, called a Work- 
Set The list describes the recentiy used objects and 
klentif ies the tools that used the particular objects. The 
present inventive method can be implemented on con- 
ventional data processing systems, personal oonrput- 
ers, workstatk>ns. arKl network servers, arxi can be 
txjndled for use in connection with conventional soft- 
ware programs used in integrated software develop- 
ment arcNtectures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Rgure 1 Is a schematic illustration of a prior art 
computer system configured to perform methods 
according to the present Invention; 
Fgure 2 Is a schematic illustration of a system for 
tracking, storing, and loading WoricSet lists, accord- 
ing to ttie present invention: 
Rgure 3 is a flowchart of a method according to an 
emt>odiment of the present invention for loading a 
central WorkSet list from a selected file; 
Rgure 4 is a flowchart of a method according to tiie 
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present invention, for saving a central WorkSet list 
to a selected file; 

Figure 5 is a flowchart of a method according to the 
present Invention for changing from a current cen- 
tral WorkSet list to a new central WorkSet list; 
Figure 6 is a flowchart showing another method 
according to the present invention tor loading a cen- 
tral WorkSet list from a selected file, to enak)le pres- 
ervation and recovery of WorkSet Information after 
crashes of particular applications which have 
received tool specif b information ttlocks; 
Figure 7 is a flowchart of a method according to the 
present invention in which central WorkSet lists are 
stored in a selected file to preserve WorkSet infor- 
mation for 8ut}sequent recovery after crash of par- 
ticular progranfts which have received tool specific 
Information blocks; and 

Figure 8 is a schematic illustration of a picklist 
which displays tool specific Information with respect 
to a WorkSet-aware tool. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Figure 1 is a schematic illustration of a conventional 
computer system 100 whk;h is used for tracking, storing, 
loading, and sharing central lists of WorkSets according 
to the present invention. Computer system 100 includes 
a computer hardware housing 102, which In turn con- 
tains a mothertx>ard 104 holding a central processing 
unit (CPU) 106 and a memory 108 associated with CPU 
106. Computer system 100 further includes a display 
card driver 110 mounted on motherboard 104. a hard 
drive 1 1 2. a floppy disk drive 1 1 4. a compact disc (CD) 
drive 1 1 8. a compact disc 1 1 9 for Installation in CD drive 
1 1 8, a computer monitor 1 20, and input devices such as 
a keyboard 122 and a mouse 124. Display card driver 
110 controls computer monitor 120. The various drives 
of computer system 100 are operable with oorresporKl- 
ing various removat)le media input output devices such 
as compact disc 119. a tape, or renrx>vat)le magneto- 
optical media (the latter not shown) having various den- 
sity media characteristics. These various components 
are interconnected in computer system 100 using 
appropriate devrce and system buses. e.g.. a SCSI bus 
or an Enhanced IDE txis. Although compact cfisc 1 19 is 
shown in a CD caddy, it can instead be inserted directly 
into CD-ROM players which do not require caddies. 
Computer system 100 may additionally include a com- 
pact disc reader/writer 1 18 and a compact disc jukebox 
(neither shown). In addition, a printer (not shewn) can 
be connected in computer system 100 to produce 
printed lists of WorkSets. Computer system 100 com- 
prises at least one computer readat)le medium. A conrv 
puter readable medium which can be used In 
connection with the present invention may be a compact 
disc, a hard disk, a floppy disk, a tape, a magneto-opti- 
cal disk, a PROM, an EPROM. an EEPROM, a Flash 



PROM, a DRAM, or an SRAM, for example. Software 
according to the present invention can be stored on any 
one or on a combination of these computer readat}le 
media as a computer program product or a part thereof. 

5 Such software can control the hardware of computer 
system 100 and can enat)le computer system 100 to 
interact with a human user. Software which can be used 
in connection with the present invention Include, but is 
not limited to. device drivers, operating systems, and 

10 user applications including software development tools. 
Computer readable media for storing such software 
includes computer program products according to the 
present invention for tracking, storing, loading, and 
sharing central WorkSet lists. 

15 A function performed on computer system 100 
according to the present invention is aeation and main- 
tenance of programs in a selected software develop- 
ment environment. Such a development environment 
errploys selected Individual tools including but not lim- 

20 ited to editors such as vi. Emacs, or text tool editors, 
assemblers, compilers, linkers, make utilities, debug- 
gers, profilers, graphical user interface tods, and ver- 
sion control systems. Due to the complexity of many 
large software projects, computer assistance in main- 

25 taining individual projects and their components is 
essential. Computer support according to the present 
invention includes an integrated software development 
environment which combines selected software tools 
under the control of an integrated software development 

30 environment manager. 

A typical maintenance cycle for a software project 
begins by editing a graphical user interface desaiption 
file to generate new source code, editing a source file to 
correct errors, or editing a source file to include code 

35 enhancements. Then, the newly ecfited code Is com- 
piled or assembled using a conrpiler or assembler, by 
invoking a make or build utility. Thereafter, the specified 
pieces are linked into a new program, and the newly 
created program Is debugged to test program fixes and 

40 enhancemerrts which have t>een made. If the mainte- 
nance cyde starts after program buikf, t>ecause of a 
speed related problem, a profiler is used to detect which 
portions of a code run consume the rrx^st execution 
time. This enables a programmer to concentrate on 

45 slow areas of code in an effort to enhance overall pro- 
gram performance. 

Atthough known source code control systems ena- 
ble a user to track the revision history of a program, 
known source code control systems do not show which 

50 tools have utilized a particular file or application and 
how the foe or application was used. As shown in 
attached Appendices A-C. the present inventk>n uses 
central WorkSet lists to track which tools have accessed 
particular fQes or source directories. In accordance with 

55 the present invention, a WortcSet manager acts as an 
integrated software environment shell witii tools which 
receive, process, and save tool specific information 200. 
An exemplary WorkSet file Is sfxywn in Appendices A-C 
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and contains a file header 220 identifying the type of the 
file, optional comments 224 Identified by a predeter- 
mined identifier. e.g.. lines starting with the number 
synix>l ("#1; and references to particular objects, e.g.. 
files or directories, which have been used by a file tool 
(such as an editor for example), a build utility, a debug- 
ger, or a graphical dass browser. In each case, tool spe- 
cific information 200 is stored in a WorkSet ffle 
accading to the present invention. In the case of a file 
tool used for tracking text files, the file specific informa- 
tion is stored in a file tool bk>ck 204 which describes par- 
ticular objects used by the file tool. A first line of file tool 
block 204 indicates that the tool tracks so-called "File- 
Data", i.e., data related to a particular file. Further, since 
typically a file tool is customarily used at the beginning 
of a software development cycle, the file tool also 
stores, on a second line, the process directory of the 
WorkSet manager, i.e., the directory in which the Work- 
Set manager was operating when a particular WorkSet 
was savedi The identifier indicates that the Informa- 
tion stored in the WorkSet file is stored in the same 
directory from which the WorkSet manager was 
launched, although not necessarily in the directory in 
which the executable version of the WorkSet manager 
exists. Since a user can instruct the text tool to store 
WorkSets in a directory different than the process direc- 
tory for the WorkSet manager, line three of the file tool 
information stores the cfirectory that the file tool cur- 
rently is using as a base directory for loading and stor- 
ing files. The current directory can be either a relative 
directory, as shown for the file tool, or an absolute direc- 
tory beginning with T, as shown for the "currentDlrec- 
tory" entry of the graphical class txowser block 216. A 
fourth line of file tool block 204 contains an object type 
identifier 235 that suggests that the particular file tool 
tracks a list of files. RIe tool block 204 particularly 
includes an incScation of which files have been used 
recently. e.g.. test.c, workset.c and 
"/home/djo/src/test/beta/bugs.lsr. As noted above, 
names of recently used files also are either relative to a 
working directory, e.g., test.c; or absolute, e.g., 
"/home/djo/src/ test/beta/bugs.lst". 

The tool specific information 200 for the buiM utility 
is provided as build block 208. This block Indicates that 
the build tool tracks "BuiWDala." The current directory of 
the build tool when the WbrkSet was saved is the same 
as the process directory. Further, object type identifier 
235 indicates that the buiki tool tracks a list of "targets" 
for build operations, i.e.. a list of programs to be built 
according to a specified set of rules contained in a 
"make" file. Build block 208 also indicates that the buiki 
utility in fact built the default target of the default "make" 
file which is stored in the "yhome/djo/src/imotrf/ch02" 
directory, by invoking a "make" contmand. In this way, 
not only are references to files saved, but associated 
directories and commands are also preserved. Simi- 
larly, debug block 212 includes an object type kfentifier 
235 that indicates that the debug tool tracks "Debug- 



Data". "Debug Data" includes a list of programs and 
specifically stores Information indicating that the pro- 
gram "yhomeAdljQ^src/rTXrtif/ch02/he!k>" has been 
debugged recently. When "hello" is debugged, "hello" is 

5 not invoked with "quickRun" option. An advantage 
derived by using a current directory as part of tool spe- 
cific information 200 is that the WorkSets thereby 
become conveniently portable between directories and 
machines. If a first programmer implements a change 

10 on a first set of source code which is being developed in 
parallel with a second set of source code, then the first 
programmer can convenientiy share the particular 
WorkSet with a second programmer for making a corre- 
sponding change In a second set of source code. 

IS Accordingly, software development time is sitetantially 
reducible by compact encapsulation of Information not 
only about files which have changed, but also about the 
associated processes by which the files have been 
changed. 

20 Although a WorkSet file has been described with a 
partk^ular stmcture herein, numerous variations of the 
foe are possible in accordance with the present inven- 
tion. Many different file layouts and line orderings can 
be employed within the meaning of the present inven- 

25 tion. Such variations in layout and orderings are distin- 
guishable by a fOe header 220 describing the selected 
variation. According to one embodiment of a WorkSet 
fBe according to the present invention, an object type 
kf entif ier 235 Includes a description of the structures of 

30 the objects in the list, rather than merely a name for the 
object type identifier 235. As Is described in detail 
below, presenting information regarding the structures 
of objects helps particular software applications. BuiM 
tools for exarrple can thereby dynamically determine 

35 formats with whrch to send or communicate particular 
entries such as program entries 260 to other software 
applications, such as a debug tool. Similarly. WorkSet 
information may be written using a formal which is self- 
describing to aid in the construction of object references 

40 for a list. 

Rgure 2 is a schematic illustration of a system 
according to the present invention, which can be imple- 
mented In many ways, including with specialized cir- 
cuitry (either hard-wired or dynamically configurable 

45 such as field programmable gate arrays), or with a cen- 
tral processing unit and associated memory. WorkSet 
manager 300 according to the present invention partic- 
ularly includes a reader/writer 304 for reading WorkSets 
from and writing WorkSets to a WorkSet storage device 

50 320 (e.g., a computer storage device such as a hard 
disk 1 12), a retainer 306 (e.g., a computer memory) for 
retaining tool specific information 200 and correspond- 
ing program identifiers 230, and a transmitter/receiver 
310 for transmitting and receiving messages to and 

55 from first and second applications which can use infor- 
mation contained in WorkSets, respectively 324 and 
328. As shown by the sequence of encircled numbers 
Indicated in Figure 2, and as descrbed in greater detail 



4 



7 

with reference to Rgures 3 and 5, WorkSet manager 
300 first reads a WorkSet stored in WorkSet storage 
device 320 by using the reader/writer 304. WorkSet 
manager 300 then utilizes retainer 306 to preserve tool 
specific information 200 and program kientif lers 230 in 5 
menrrory 314 for unregistered blocks. Transmit- 
ter/receiver 310 then transmits tool specific information 
200 to the partrcuiar one of applications (324 and 328) 
which has registered that tool specifk; information 200 
corresponding to the current program identifier 230 10 
should be sent to it Conversely, when storing a Work- 
Set, as shown by the numbers contained in squares 
shown in Rgure 2, arxj as desaibed in greater detail 
with respect to Figures 4 and 7, WorkSet manager 300 
coordinates collection and storage of tool specific infor- 75 
mation 200 from each of the applications and writes col- 
lected and retained tool specrfk; information 200 to 
WorkSet storage device 320. 

Figure 3 shows in greater detail a method accord- 
ing to the present invention for reading a WorkSet by a 20 
WorkSet manager 300 and transmitting tool specific 
information 200 to partknjlar applications 324 and 328. 
In step 400, a selected WorkSet file, such as the Work- 
Set file shown above for example, ts opened and read 
line-by-line until, ignoring comments 224, a first pro- 25 
gram identifier 230 is found. Program identifiers are 
shown beginning with an unusual character pair such as 
"%%" for ©cample to aid in parsing tiie WorkSet file. 
According to step 404, the WorkSet file is read line-by- 
line until a next program kJentifier 230 or an end of file is 30 
reached. In the case of a '%%File" program Wentifier 
230, the lines of file tool block 204 are assembled as a 
block of lines of text. In step 408, WorkSet manager 300 
deternfvnes tiiat a WbricSet-aware application (324 or 
328), e.g., a modified version of Emacs, has been regis- 35 
tered to process file tool block 204. Since step 410 
determines that there is a WorkSet^aware program 
(e.g., 324 or 328) that is registered for '%%Rle'' pro- 
gram identifier 230, WorkSet manager 300 continues to 
step 41 6 and sends the kientif ied block of lines of text to 40 
the program that registered the cunent program kienti- 
f ier 230, i.e., the '%%nie" identifier. TTiis block of lines 
of text may be sent through any appropriate conrununi- 
cation mechanism, e.g., sockets, shared memory, 
named pipes, or windowing messages, as the case may 45 
be. In an integrated software development environment. 
Todtalk® messages are one method of sending mes- 
sages between WorkSet-aware applications. Toottalk is 
a name which has been registered by Sun Mk^^osys- 
Xerns, Inc.. as a trademark with the US. Patent and so 
Trademark Office. Toottalk is an inter-application com- 
munication protocol system prcvkiing a useful messag- 
ing service which enak)les convenient tool interchanges. 
Also, although described in terms of blocks of lines of 
text for convenience and ease of explanation, the blocks ss 
may include t}inary or compressed data, according to an 
embodiment of the present invention. Each of these 
representations is intended to be covered by the phrase 
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Information blocks" as in file tool block 204 or buiki 
block 208. 

Continuing with the description of Rgure 3, if 
according to step 410 it has been determined that no 
program has been registered for a nrK>st recently read 
program identifier 230, or that the program that was reg- 
istered for this program identifier 230 could not be 
started, tiien WorkSet manager 300 nKves from step 
410 to step 412. According to step 412, WorkSet n^- 
ager 300 stores a block of lines of text internally so that 
WorkSet manager 300 can write the same block back 
out to the WorkSet file when the WorkSet is saved. By 
internally storing the block of lines of text, WorkSet man- 
ager 300 prevents useful tool specific information 200 
from being discarded from the WorkSet during times in 
whk;h a program which is normally registered for a pro- 
gram klentifier has t>een accidentally unregistered or is 
temporarily unavailable. e.g., because of a network fail- 
ure. WorkSet manager 300 transitions to step 420 after 
both steps 416 and 412 have been accomplished, and 
in step 420 WorkSet manager 300 determines whether 
or not there is more text in the WorkSet file which repre- 
sents new tool specif ic information 200. 

Rgure 4 is a flowchart showing how a WorkSet is 
saved according to an embodiment of the saving 
method. This saving metftod is used with a WorkSet 
that is loaded according to the method of Rgure 4. In 
step 500. WorkSet manager 300 opens a f De into which 
the current WorkSet is to be written. Step 504 writes to 
the current WorkSet file any program klentifiers and 
blocks that were stored internally, but for which no reg- 
istered program has been found or started. According to 
step 508, a collection message is sent to a first regis- 
tered WorkSet-aware application (324 or 328) to 
request that the first registered application send Work- 
Set manager 300 a first information block. The first infor- 
mation block is to be stored in the current WorkSet file 
on behalf of the first registered application. In step 512. 
when the WorkSet manager 300 receives the informa- 
tion block which is to be stored in tiie current WbrkSet 
file. Workset manager 300 transitions to step 516 to 
write out the program identifier 230 followed t>y the 
received first information block from the first registered 
application. In the decision step 520, WorkSet manager 
300 determines whether or not more registered applica- 
tions exist, and if so. WorkSet manager 300 transitions 
to step 524. In step 524. ttie next registered application 
is sent a message, and the processing loop of steps 
512, 516 and 520 is repeated for the next registered 
applk:ation arxl its associated information t>lock. If step 
520 determines that there are no more registered appli- 
cations, control passes to step 530 so that the file for the 
cun'ent WorkSet file can be closed for later retrieval, 
copying, or sharing. 

In addition, since WbrkSets are self-contained enti- 
ties, a current WbrkSet can t>e saved and a new Work- 
Set opened when a user is changing between separate 
activities. In this way, a user can easily distinguish 
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between a WorkSet for a first project and a WorkSet for 
a second project. Rgure 5 shows a process for chang- 
ing between WorkSets. In step 600, the current Work- 
Set is written out according to the method of Figure 4 or 
Rgure 7. In step 604, WorkSet nnanager 300 receives 
the name or other Identifier of another WorkSet to use 
instead of the current WorkSet. In step 608, the Work- 
Set manager 300 then opens the other WorkSet as a 
new current WorkSet. Step 608 can be performed by 
the methods of Rgure 3 and Rgure 6 respectively after 
the writing of step 600 has been performed using the 
methods of Rgures 4 and 7, respectively. 

Rgure 6 Is a flowchart of another embodiment 
according to the present invention, desaibing the proc- 
ess of loading WorkSets according to the present inven- 
tion from a selected WorkSet file and sending tool 
specific information 200 to specific registered applica- 
tions. Steps 700 and 704 Involve performance of steps 
similar or equivalent to corresponding steps 400 and 
404 of Rgure 3, during which time the applicable Work- 
Set file is opened and read line-by-line until a first set of 
tool specific information 200 has t>een read. In step 706, 
WorkSet manager 300 stores the most recently read 
information block received from the WorkSet file. In the 
processing of the file according to Rg. 7, this informa- 
tion block can be saved back to the WorkSet file in case 
there is no application registered for tiiis program iden- 
tifier, or In case there is a registered application for tNs 
program identifier but the registered application cannot 
be started, or in case there is a registered application 
for this program identifier and it has been started but the 
registered application is not responding to requests for 
tool specific information 200. If the registered applica- 
tion has amerxJed its tool specific information 200 but 
has then crashed, WorkSet manager 300 writes out pre- 
vious tool-specific information 200 to a cunrent WorkSet 
file. After step 706, the method according to the present 
invention continues with step 710 to determine whether 
or not tiiere is a registered application according to this 
program identifier 230. If such an application is identi- 
fied, control passes to step 714 which calls for sending 
the information block to the application tiiat registered 
the current program identifier 230. Control passes from 
botii steps 714 and 710 to step 720 where it is deter- 
nnined whether or not more text exists in the current 
WorkSet file. If step 720 determines that there is more 
text, control is returned to step 704 to repeat the 
processing- - of steps 704/706/710/720 or 
704/706/710/714/720 until step 720 determines that no 
woTQ text is availat}le in the WorkSet file. 

Rgure 7 is a flowchart showing another embodi- 
ment according to the present invention, including stor- 
ing data according to the present invention into a 
WorkSet fie under the control of a WorkSet manager 
300 witti the cooperation of WorkSet-aware applica- 
tions. According to step 800, the file into which the cur- 
rent WorkSet is to t>e written is opened. Then, according 
to step 804 any tool specific information 200 is written 



out, including a program identifier 230 that was stored 
internally after reading in the WorkSet, by using the 
mettiod of Figure 6. but for which no registered applica- 
tion couki be found. According to step 808. the first reg- 

5 istered application 324 is sent a message to cause it to 
return its tool specific information 200 to be added to the 
current WorkSet fila According to step 810, it is deter- 
mined whether or not the first registered application 
returned an information block, e.g., a file tool block 204. 

10 If according to step 81 0 it is determined that an informa- 
tion block has not been returned, control passes to step 
814. According to step 814, WorkSet manager 300 
writes out tiie current program identifier 230 and further 
writes the original irrformation block for the first regis- 

75 tered application 324, which were originally stored in the 
WorkSet file, to the current WorkSet f 9e. If according to 
step 810, it is determined that tiie information block has 
been returned, the method of storing continues with 
step 812. In step 812, WorkSet manager 300 receives 

20 an information block and passes to step 81 6 to write out 
to the current WorkSet f3e tool specific information 
including a program identifier and the information block 
received from the applicable application. After accom- 
plishment of either step 814 or step 816, control passes 

25 to step 820 which determines whether or not any addi- 
tional registered applications exist to be contacted. If 
wore registered applications exist, conti-ol passes from 
step 820 to step 824 so that a message can be sent to 
tiie next registered application. From step 824. control is 

30 returned to step 810 to determine whether or not a next 
registered application has returned an information 
bkx^k, or if tiiere appears to be an error which prevented 
tiie information block from fc>eing returned. After steps 
810 through 820 are completed and step 820 deter- 
as mines tiiat there are no nwre registered applications, 
control Is passed to step 830 which causes the current 
WorkSet file to be closed for later retrieval, copying, or 
sharing. 

Although discussed atxve in terms of references to 

40 recently used oksjects, WorkSets can also represent ref- 
erences to objects which are expected to be used at a 
later time in an integrated software development envi- 
ronment For example, as buiM target 250 of tiie build 
t)k>ck 208 shows in Appendix A. the build tool has 

45 recently buitt a default target of the default Makefile in 
tiie directory ''yhome/djo/src/irTK]tif/ch02*' by invoking the 
"make" command. If the buiki tool buitols the program 
"hello" through the "make" process, the build utility may 
also send the debugger application a message indicat- 

50 ing that there is a "new" program which the user may be 
interested in detxigging. Based on this information, the 
debugger can add the program "hello" to debug infor- 
mation 21 2. as is shown at program block 260 in Appen- 
dix C. This process of passing tool specif k; information 

55 200 between applications is aided by the use of tiie 
description of the structure of an otsject identified by 
otiject type klentifier 235. Applications using the struc- 
ture information are aided in sending compatible mes- 
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sages based on the structure. Otherwise, the receiving 
application may be forced to perform nx>re extensive 
error checking when receiving tool specific Information 
200. or applications may accidentally send out of date 
structures between applications. 5 

In addition to storing lists of recentiy used objects, 
the present invention also enconrpasses displaying par- 
ticular lists to a human user to aid in software develop- 
ment. Although particular lists can be printed, the lists 
are desirably displayed as dynamic extensions to 10 
selected menu items. These extensions are called pick- 
lists, as shown in Rgure 8. The process of passing mes- 
sages t>etween cooperating applications and 
synchronizing the picMists of an integrated software 
environment manager and individual tools of the inte- is 
grated software environment is described in detail in a 
copending application entitied Third-Party Tool Integra- 
tion." 

Also, although discussed atX3ve in terms of adding 
new infornDation to tool specific information 200 to 20 
reflect recently used or soon-to-be-used objects, object 
references may also be renrxived from tool specific infor- 
mation 200 by tools, including the integrated software 
environment manager. By removing references to unin- 
tentionally visited objects or objects that a first tool 25 
believes a second tool will use soon but which are rxit 
actually used, the tool specific information 200 can be 
reduced to more compactly describe intended interac- 
tions of a user which are recorded in a WorkSet file. A 
method for renmving entries from tool specific informa- 30 
tion 200 is further described in the above-referenced 
copending application relating to Picklist Editing, and a 
method for synchronizing tiie removal of entries from 
plural tools in an integrated software environment is 
descrbed in the copending application entitied Third- 35 
Party Tool Integration." 

In addition, although discussed above in terms of 
saving WorkSets to and loading WbrkSets from files, 
the present invention also encompasses using a data- 
base to save and load WorkSets. The reader/writer 304 40 
which reads and writes files would according to such an 
embodiment be replaced by a modWiBd readerywrrter 
304* which uses database commands to perform the 
saving and loading. For example, when using an SQL- 
style database, entries added according to the present 45 
invention by using "inserT commands are nrKXiified 
using "update" commands, and are retrieved using 
"select" commands. With such a nxxiified system, tool 
specific information 200 of unregistered applications is 
not stored internally in WorkSet manager 300 and writ- so 
ten out to a WorkSet file when saving the f Oe. Instead, 
tiie tool specific information 200 is automatically 
retained in the datat^ase. and retainer 31 4 consequentiy 
is omitted. 

Numerous modifications and variations of the ss 
present invention are possitrfe in light of the above 
teachings. It is therefore to be understood that, within 
the scope of the appended claims, the invention may be 



practiced otherwise than as specifically described 
herein. 

Claims 

1. A computer system for centrally managing refer- 
ences to an object used by a selected application, 
the computer system comprising: 

a computer storage device; 
a transmitter configured to send a collection 
message to plural applications in a selected 
software environment; 

a receiver configured to receive an information 
block from at least one application in response 
to the collection message, the information 
block including references to objects recentiy 
used by the at least one application; and 
a writer configured to write information blocks 
received from the at least one application to the 
conrputer storage device. 

2. The computer system according claim 1 , wherein 
tiie writer further comprises a program identifier 
writer configured to wr'rte a conesponding program 
kient'rfier to the computer storage device for the 
information block received from the at least one 
application. 

3. The computer system according to claim 2, further 
conprising a reader corrfigured to read a second 
set of at least one information block from the com- 
puter storage device, wherein the transmitter is 
configured for transmitting the second set of at least 
one inforn^tion block read by tiie reader, or at least 
one selected application. 

4. The computer system according to daim 2, further 
comprising a reader configured to read the informa- 
tion t>locks writtOT by the writer, wherein the trans- 
mitter is configured for transmitting at least one 
information block read by the reader to at least one 
application. 

5. The connputer system according to daim 1 , wherein 
the computer storage device comprises a hard disk. 

6. The computer system according to daim It^^^erein 
tiie computer storage device corrprises a data- 
base. 

7. The computer system according to claim 1 , wherein 

the transmitter comprises a transmitter config- 
ured to transmit ToolTalk messages; and 
the receiver comprises a receiver configured to 
receive ToolTalk messages. 
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8. A method for managing references to objects 
recently used l>y a selected one or more applica- 
tions in a computer, the method comprising the 
steps of: 

5 

transmitting a collection message to plural 
applications in a selected software environ- 
ment; 

receiving an information block from at least one 
application in response to the collection mes- io 
sage, the information block including refer- 
ences to objects recently used by the at least 
one application; and 

writing the irtformation blocks received from the 
at least one application to a selected computer is 
storage device. 

9. The method according to claim 8. including writing 
a corresponding program identifier to the computer 
storage device for an information block received 20 
from the at least one application. 

10. The method accordng to daim 9, further compris- 
ing: 

25 

reading a second set of at least one information 
blocks from the computer storage device; and 
transmitting the second set of at least one infor- 
mation block to at least one application. 

30 

11. The method according to daim 9, further compris- 
ing: 

reading an informatfon tHock which has been 
written in a computer storage device; and 35 
transmitting at least one of the information 
blocks which has been read, to a selected 
application. 

12. The method according to daim 8. wherein writing to 40 
the corrputer storage device corrprises writing to a 
hard cfisk. 

1 3. The method according to daim 8, wherein writing to 
the computer storage device corrprises writing to a 45 
selected datat>ase. 

14. The method according to daim 8, comprising 

transmitting ToolTalk messages; and so 
receiving ToolTalk messages. 

15. A computer program product, comprising: 

a corrputer storage medium and a corrputer ss 
program code mechanism embedded in the 
corrputer storage medium for causing a com- 
puter to manage references to objects used by 



plural applications, the computer program code 
mechanism comprising: 

a first computer code device configured to 
transmit a collection message to plural 
applications in a software development 
environment; 

a second computer code device config- 
ured to receive an information block from 
at least one application of the plural appli- 
cations in response to the collection mes- 
sage, the information block including 
references to objects used by the at least 
one application; and 

a third computer code device configured to 
write information blocks received from at 
least one application to a selected corrpu- 
ter storage device. 

16. The corrputer program product according to daim 
15, wherein the third corrputer code device fulher 
comprises a fourth computer code device config- 
ured to write a corresponding program identifier to 
the corrputer storage device for the information 
block received from at least one applfoatfon. 

17. The corrputer program product according to daim 
15, further comprising: 

a fourth corrputer code device configured to 
read a second set of at least one information 
blocHs from the conputer storage device; and 
a fifth computer code device configured to 
transm'rt the second set of at least information 
blocks to at least one of the plural applications. 

18. The corrputer program product according to daim 
15, further comprising: 

a fourth computer code device configured to 
read the information blocks written by the third 
computer code device; and 
a fifth computer code device configured to 
transmit at least one of the information blocks 
read in by the fourth computer code device to a 
new set of at least one applicatfon. 

19. The corrputer program product according to daim 
15. wherein the third computer code device is con- 
figured to write to a hard disk. 

20. The corrputer program product according to daim 
15. wherein the first corrputer code device is con- 
figured to transmit ToolTalk messages; and 

wherein the second corrputer code device is 
corrf igured to receive ToolTalk messages. 
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OPEN WORKSET FILE AND READ WORKSET FILE LINE-BY- 
LINE UNTIL FIRST PROGRAM IDENTIFIER IS READ. 

400 



READ ALL LINES OF WORKSET FILE CORRESPONDING TO 
THE CURRENT PROGRAM IDENTIFIER INTO A BLOCK OF 
LINES OF TEXT. END DETERMINED BY READING NEXT 
PROGRAM IDENTIFIER OR END-OF-FILE. 
404 



DETERMINE IF A PROGRAM IS REGISTERED FOR THAT 
PROGRAM IDENTIFIER. 
408 



PROGRAM 
REGISTERED FOR 
THIS PROGRAM 
IDENTIFIER? 
410 



STORE BLOCK OF LINES 
OF TEXT INTERNALLY TO 
ALLOW BLOCK TO BE 
WRIHEN OUT WHEN 
WORKSET IS SAVED. 
412 



SEND BLOCK OF TEXT TO THE PROGRAM THAT 
REGISTERED THE CURRENT PROGRAM IDENTIFIER SO 
THAT THE PROGRAM CAN PARSE DATA TO BUILD AN 
APPLICATION-SPECIFIC WORKSET. 
416 



10RE 

IN WORKSET FILE? ^ 
420 



N 



END 



FIG. 3 
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OPEN FILE INTO WHICH THE CURRENT WORKSET IS TO BE WRIHEN. 

m 

WRITE OUT ANY PROGRAM IDENTIFIERS AND BLOCKS THAT WERE 
STORED INTERNAaV AFTER READING IN THE WORKSET BUT FOR 
WHICH NO REGISTERED PROGRAM COULD BE FOUND. 
504 

SEND MESSAGE TO A FIRST REGISTERED PROGRAM. 

508 



SEND MESSAGE TO THE 
NEXT REGISTERED 
PROGRAM. 
524 


> 


RECEIVE FROM THE PROGRAM A BLOCK 
OF LINES OF TEXT WHICH ARE TO BE 
STORED INT HE CURRENT WORKSET. 
512 
















WRITE OUT PROGRAM IDENTIFIER TO FILE FOR THE 
CURRENT WORKSET, FOLLOWED BY THE RECEIVED 
BLOCK OF LINES OF TEXT. 
516 






Y ^ 
— —>< 




/MORE\ 

registeredX. 



PROGRAMS? 
\ 520^ 



CLOSE FILE FOR THE CURRENT 
WORKSET. 
530 



FIG. 4 
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WRITE-OUT THE CURRENT WORKSET. 



RECEIVE NEW WORKSET TO MAKE THE CURRENT WORKSET. 

604 



I 

OPEN NEW CURRENT WORKSET AND SEND CORRESPONDING 
BLOCKS OF LINES OF TEXT TO REGISTERED. 
608 




FIG. 5 



EP0851 347 A2 




OPEN WORKSET FILE AND READ WORKSET FILE UNE-BY- 
LINE UNTIL FIRST PROGRAM IDENTIFIER IS READ. 

700 



READ ALL UNES OF WORKSET FILE CORRESPONDING TO 
THE CURRENT PROGRAM IDENTIFIER INTO A BLOCK OF 
LINES OF TEXT. END DETERMINED BY READING NEXT 
PROGRAM IDENTIFIER OR END-OF-FILE. 
704 



STORE BLOCK OF LINES OF TEXT INTERNALLY SO THAT 
BLOCK CAN BE WRIHEN OUT WHEN WORKSET IS SAVED. 
REGARDLESS OF WHETHER OR NOT A PROGRAM IS 
REGISTERED FOR THIS TYPE OF DATA. 
706 



PROGRAM 
REGISTERED FOR THIS 
PROGRAM IDENTIFIER? 
710 



N 

'MORETEXf 
IN WORKSET FILE? >^ 

720 



SEND BLOCK OF TEXT TO 
THE PROGRAM THAT 
REGISTERED THE CURRENT 
PROGRAM IDENTIFIER SO 
THAT THE PROGRAM CAN 
PARSE DATA TO BUILD AN 
APPLICATION-SPECIFIC 
WORKSET. 
714 



FIG 6 
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OPEN FILE INTO WHICH THE CURRENT WORKSET IS TO BE WRITTEN. 

800 



WRITE OUT ANY PROGRAM IDENTIFERS AND BLOCKS THAT WERE 
STORED INTERNALLY AFTER READING IN THE WORKSET BUT FOR 
WHICH NO REGISTERED PROGRAM COULD BE FOUND. 

804 



SEND MESSAGE TO A FIRST REGISTERED PROGRAM. 

808 



BID 

»ROGRAMRETUR^ 
ABLOCKOFUNESOF 
TEXT? 
810 



WRITE PROGRAM IDENTIFIER AND 
ORIGINAL BLOCK OF LINES OF TEXT FOR 
THIS PROGRAM, WHICH WERE STORED IN 
THE WORKSET FILE. BACK OUT TO THE 
WORKSET FILE. 
814 



SEND MESSAGE TO THE NEXT 
REGISTERED PROGRAM. 
824 



RECEIVE FROM THE PROGRAM A BLOCK 
OF LINES OF TEXT WHICH ARE TO BE 
STORED IN THE CURRENT WORKSET. 
812 



WRITE OUT PROGRAM IDENTIFIER TO 
FILE FOR THE CURRENT WORKSET. 
FOLLOWED BY THE RECEIVED BLOCK 
OF UNESOFTEXT. 
816 



CLOSE FILE FOR THE CURRENT 
WORKSET. 
830 



^END^ 



FIG. 7 
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EILE BUILD DEBUG BROWSE 




NEW 

OPEN 

CLOSE 



/USR/DJ0/SRC/TEMP/FILE1 
/USR/DJ0/SRC/TEMP/FILE2 
/USR/DJ0/SRC/TEMP/FILE3 



REMOVE AN ENTRY 



^|TP2i|TP3l 
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FIG. 8 
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